Typsichere Nachrichtenwarteschlangen: Der Eckpfeiler moderner ereignisgesteuerter Architekturen

In der sich rasant entwickelnden digitalen Landschaft von heute ist der Aufbau widerstandsfähiger, skalierbarer und anpassungsfähiger Softwaresysteme von größter Bedeutung. Ereignisgesteuerte Architekturen (EDA) haben sich als dominierendes Paradigma zur Erreichung dieser Ziele herausgebildet und ermöglichen es Systemen, in Echtzeit auf Ereignisse zu reagieren. Im Herzen jeder robusten EDA liegt die Nachrichtenwarteschlange, eine entscheidende Komponente, die die asynchrone Kommunikation zwischen verschiedenen Diensten ermöglicht. Wenn die Systeme jedoch komplexer werden, entsteht eine kritische Herausforderung: die Gewährleistung der Integrität und Vorhersagbarkeit der ausgetauschten Nachrichten. Hier kommen typsichere Nachrichtenwarteschlangen ins Spiel und bieten eine robuste Lösung für Wartbarkeit, Zuverlässigkeit und Entwicklerproduktivität in verteilten Systemen.

Dieser umfassende Leitfaden befasst sich mit der Welt der typsicheren Nachrichtenwarteschlangen und ihrer zentralen Rolle in modernen ereignisgesteuerten Architekturen. Wir werden die grundlegenden Konzepte von EDA untersuchen, verschiedene Architekturmuster betrachten und hervorheben, wie Typsicherheit Nachrichtenwarteschlangen von einfachen Datentransitwegen in zuverlässige Kommunikationskanäle verwandelt.

Verständnis ereignisgesteuerter Architekturen (EDA)

Bevor wir uns mit Typsicherheit befassen, ist es wichtig, die Kernprinzipien ereignisgesteuerter Architekturen zu verstehen. Eine EDA ist ein Softwareentwurfsmuster, bei dem der Informationsfluss durch Ereignisse gesteuert wird. Ein Ereignis ist ein bedeutendes Vorkommnis oder eine Zustandsänderung innerhalb eines Systems, an dem andere Teile des Systems interessiert sein könnten. Anstelle von direkten, synchronen Anfragen zwischen Diensten verlässt sich EDA darauf, dass Produzenten Ereignisse ausgeben und Konsumenten darauf reagieren. Diese Entkopplung bietet mehrere Vorteile:

• Entkopplung: Dienste müssen die Existenz oder Implementierungsdetails anderer Dienste nicht direkt kennen. Sie müssen nur die Ereignisse verstehen, die sie produzieren oder konsumieren.
• Skalierbarkeit: Einzelne Dienste können unabhängig von ihrer spezifischen Auslastung skaliert werden.
• Widerstandsfähigkeit: Wenn ein Dienst vorübergehend nicht verfügbar ist, können andere weiterhin betrieben werden, indem sie Ereignisse später verarbeiten oder Wiederholungsversuche unternehmen.
• Echtzeit-Reaktionsfähigkeit: Systeme können sofort auf Änderungen reagieren und Funktionen wie Live-Dashboards, Betrugserkennung und IoT-Datenverarbeitung ermöglichen.

Nachrichtenwarteschlangen (auch bekannt als Nachrichtenbroker oder Message-Oriented Middleware) sind das Rückgrat von EDA. Sie fungieren als Vermittler, speichern Nachrichten vorübergehend und liefern sie an interessierte Konsumenten. Beliebte Beispiele sind Apache Kafka, RabbitMQ, Amazon SQS und Google Cloud Pub/Sub.

Die Herausforderung: Nachrichtenschemata und Datenintegrität

In einem verteilten System, insbesondere in einem, das EDA verwendet, werden mehrere Dienste Nachrichten produzieren und konsumieren. Diese Nachrichten repräsentieren oft Geschäftsereignisse, Zustandsänderungen oder Datentransformationen. Ohne einen strukturierten Ansatz für Nachrichtenformate können mehrere Probleme auftreten:

• Schema-Entwicklung: Da sich Anwendungen weiterentwickeln, werden sich Nachrichtenstrukturen (Schemata) unweigerlich ändern. Wenn dies nicht richtig gehandhabt wird, senden Produzenten möglicherweise Nachrichten in einem neuen Format, das Konsumenten nicht verstehen, oder umgekehrt. Dies kann zu Datenbeschädigung, verlorenen Nachrichten und Systemausfällen führen.
• Datentyp-Fehlpaarungen: Ein Produzent sendet möglicherweise einen ganzzahligen Wert für ein Feld, während ein Konsument einen String erwartet, oder umgekehrt. Diese subtilen Typ-Fehlpaarungen können Laufzeitfehler verursachen, die in einer verteilten Umgebung schwer zu debuggen sind.
• Mehrdeutigkeit und Fehlinterpretation: Ohne eine klare Definition der erwarteten Datentypen und Strukturen können Entwickler die Bedeutung oder das Format von Nachrichtenfeldern falsch interpretieren, was zu fehlerhafter Logik in Konsumenten führt.
• Integrationshölle: Die Integration neuer Dienste oder die Aktualisierung bestehender Dienste wird zu einem mühsamen Prozess der manuellen Überprüfung von Nachrichtenformaten und der Behandlung von Kompatibilitätsproblemen.

Diese Herausforderungen verdeutlichen die Notwendigkeit eines Mechanismus, der Konsistenz und Vorhersagbarkeit beim Nachrichtenaustausch erzwingt – die Essenz der Typsicherheit in Nachrichtenwarteschlangen.

Was sind typsichere Nachrichtenwarteschlangen?

Typsichere Nachrichtenwarteschlangen beziehen sich im Kontext von EDA auf Systeme, bei denen die Struktur und die Datentypen von Nachrichten formal definiert und durchgesetzt werden. Das bedeutet, dass ein Produzent, wenn er eine Nachricht sendet, einem vordefinierten Schema entsprechen muss, und wenn ein Konsument sie empfängt, wird garantiert, dass sie die erwartete Struktur und die erwarteten Typen aufweist. Dies wird typischerweise erreicht durch:

• Schema-Definition: Eine formale, maschinenlesbare Definition der Nachrichtenstruktur, einschließlich Feldnamen, Datentypen (z. B. String, Integer, Boolean, Array, Objekt) und Einschränkungen (z. B. erforderliche Felder, Standardwerte).
• Schemaregister: Ein zentrales Repository, das diese Schemata speichert, verwaltet und bereitstellt. Produzenten registrieren ihre Schemata, und Konsumenten rufen sie ab, um die Kompatibilität sicherzustellen.
• Serialisierung/Deserialisierung: Bibliotheken oder Middleware, die die definierten Schemata verwenden, um Daten für die Übertragung in einen Byte-Stream zu serialisieren und sie bei Empfang zurück in Objekte zu deserialisieren. Diese Prozesse validieren die Daten inhärent gegen das Schema.

Das Ziel ist es, die Last der Datenvalidierung von der Laufzeit auf die Kompilierzeit oder frühe Entwicklungsphasen zu verlagern, wodurch Fehler leichter erkennbar werden und verhindert wird, dass sie in die Produktion gelangen.

Wichtige Vorteile typsicherer Nachrichtenwarteschlangen

Die Einführung typsicherer Nachrichtenwarteschlangen bringt eine Vielzahl von Vorteilen für ereignisgesteuerte Systeme:

• Verbesserte Zuverlässigkeit: Durch die Durchsetzung von Datenverträgen reduziert Typsicherheit die Wahrscheinlichkeit von Laufzeitfehlern aufgrund von fehlerhaften oder unerwarteten Nachrichten-Payloads erheblich. Konsumenten können den erhaltenen Daten vertrauen.
• Verbesserte Wartbarkeit: Die Schema-Entwicklung wird zu einem verwalteten Prozess. Wenn ein Schema geändert werden muss, geschieht dies explizit. Konsumenten können aktualisiert werden, um neue Versionen von Schemata zu verarbeiten, wodurch die Abwärts- oder Vorwärtskompatibilität nach Bedarf gewährleistet wird.
• Schnellere Entwicklungszyklen: Entwickler verfügen über klare Definitionen von Nachrichtenstrukturen, wodurch Rätselraten und Mehrdeutigkeiten reduziert werden. Tools können oft Code (z. B. Datenklassen, Schnittstellen) basierend auf Schemata generieren, was die Integration beschleunigt und Boilerplate-Code reduziert.
• Vereinfachtes Debugging: Wenn dennoch Probleme auftreten, hilft Typsicherheit dabei, die Ursache schneller zu identifizieren. Fehlpaarungen werden oft frühzeitig in der Entwicklungs- oder Testphase erkannt oder durch den Serialisierungs-/Deserialisierungsprozess deutlich angezeigt.
• Ermöglicht komplexe EDA-Muster: Muster wie Event Sourcing und CQRS (Command Query Responsibility Segregation) sind stark auf die Fähigkeit angewiesen, Ereignissequenzen zuverlässig zu speichern, wiederzugeben und zu verarbeiten. Typsicherheit ist entscheidend für die Gewährleistung der Integrität dieser Ereignisströme.

Gängige ereignisgesteuerte Architekturmuster und Typsicherheit

Typsichere Nachrichtenwarteschlangen sind grundlegend für die effektive Implementierung verschiedener fortschrittlicher EDA-Muster. Lassen Sie uns einige untersuchen:

1. Publish-Subscribe (Pub/Sub)

Im Pub/Sub-Muster senden Publisher Nachrichten an ein Thema, ohne zu wissen, wer die Subscriber sind. Subscriber interessieren sich für bestimmte Themen und erhalten Nachrichten, die an sie veröffentlicht werden. Nachrichtenwarteschlangen implementieren dies oft über Themen oder Exchanges.

Auswirkungen der Typsicherheit: Wenn Dienste Ereignisse (z. B. `OrderCreated`, `UserLoggedIn`) an ein Thema veröffentlichen, stellt die Typsicherheit sicher, dass alle Subscriber, die dieses Thema konsumieren, diese Ereignisse mit einer konsistenten Struktur erwarten. Ein `OrderCreated`-Ereignis könnte beispielsweise immer `orderId` (string), `customerId` (string), `timestamp` (long) und `items` (ein Array von Objekten mit `productId` und `quantity`) enthalten. Wenn ein Publisher später `customerId` von String zu Integer ändert, werden das Schemaregister und der Serialisierungs-/Deserialisierungsprozess diese Inkompatibilität kennzeichnen und die Verbreitung fehlerhafter Daten verhindern.

Globales Beispiel: Eine globale E-Commerce-Plattform könnte ein `ProductPublished`-Ereignis haben. Verschiedene regionale Dienste (z. B. für Europa, Asien, Nordamerika) abonnieren dieses Ereignis. Typsicherheit stellt sicher, dass alle Regionen das `ProductPublished`-Ereignis mit konsistenten Feldern wie `productId`, `name`, `description` und `price` (mit einem definierten Währungsformat oder einem separaten Währungsfeld) erhalten, auch wenn die Verarbeitungslogik für jede Region variiert.

2. Event Sourcing

Event Sourcing ist ein Architekturmuster, bei dem alle Änderungen am Anwendungszustand als eine Sequenz unveränderlicher Ereignisse gespeichert werden. Der aktuelle Zustand einer Anwendung wird durch das Wiedergeben dieser Ereignisse abgeleitet. Nachrichtenwarteschlangen können als Ereignisspeicher oder als Weiterleitung dazu dienen.

Auswirkungen der Typsicherheit: Die Integrität des Zustands des gesamten Systems hängt von der Genauigkeit und Konsistenz des Ereignisprotokolls ab. Typsicherheit ist hier nicht verhandelbar. Wenn ein Ereignisschema weiterentwickelt wird, muss eine Strategie für die Verarbeitung historischer Daten vorhanden sein (z. B. Schema-Versionierung, Ereignistransformation). Ohne Typsicherheit könnte das Wiedergeben von Ereignissen zu beschädigten Zuständen führen und das System unzuverlässig machen.

Globales Beispiel: Ein Finanzinstitut könnte Event Sourcing für Transaktionshistorien verwenden. Jede Transaktion (Einzahlung, Auszahlung, Überweisung) ist ein Ereignis. Typsicherheit stellt sicher, dass historische Transaktionsdatensätze konsistent strukturiert sind, was eine genaue Überwachung, Abgleichung und Zustandsrekonstruktion über verschiedene globale Niederlassungen oder Aufsichtsbehörden hinweg ermöglicht.

3. Command Query Responsibility Segregation (CQRS)

CQRS trennt die Modelle, die zum Aktualisieren von Informationen (Befehle) verwendet werden, von den Modellen, die zum Lesen von Informationen (Abfragen) verwendet werden. Oft führen Befehle zu Ereignissen, die dann zum Aktualisieren von Lese-Modellen verwendet werden. Nachrichtenwarteschlangen werden häufig verwendet, um Befehle und Ereignisse zwischen diesen Modellen zu propagieren.

Auswirkungen der Typsicherheit: Befehle, die an die Schreibseite gesendet werden, und Ereignisse, die von der Schreibseite veröffentlicht werden, müssen strengen Schemata entsprechen. Ebenso müssen Ereignisse, die zum Aktualisieren von Lese-Modellen verwendet werden, konsistente Formate aufweisen. Typsicherheit stellt sicher, dass der Befehlshandler eingehende Befehle korrekt interpretiert und dass die generierten Ereignisse zuverlässig von anderen Diensten und den Projektoren des Lese-Modells verarbeitet werden können.

Globales Beispiel: Ein Logistikunternehmen könnte CQRS zur Verwaltung von Sendungen verwenden. Ein `CreateShipmentCommand` wird an die Schreibseite gesendet. Nach erfolgreicher Erstellung wird ein `ShipmentCreatedEvent` veröffentlicht. Die Konsumenten des Lese-Modells (z. B. für Tracking-Dashboards, Lieferbenachrichtigungen) verarbeiten dann dieses Ereignis. Typsicherheit garantiert, dass das `ShipmentCreatedEvent` alle notwendigen Details wie `shipmentId`, `originAddress`, `destinationAddress`, `estimatedDeliveryDate` und `status` in einem vorhersagbaren Format enthält, unabhängig vom Ursprung des Befehls oder dem Standort des Lese-Modell-Dienstes.

Implementierung von Typsicherheit: Werkzeuge und Technologien

Die Erzielung von Typsicherheit in Nachrichtenwarteschlangen umfasst typischerweise eine Kombination aus Serialisierungsformaten, Schema-Definitionssprachen und spezialisierten Werkzeugen.

1. Serialisierungsformate

Die Wahl des Serialisierungsformats spielt eine entscheidende Rolle. Einige beliebte Optionen mit Schema-Durchsetzungsfähigkeiten sind:

• Apache Avro: Ein Daten-Serialisierungssystem, das Schemata in JSON verwendet. Es ist kompakt, schnell und unterstützt Schema-Entwicklung.
• Protocol Buffers (Protobuf): Ein sprachneutraler, plattformneutraler, erweiterbarer Mechanismus zur Serialisierung strukturierter Daten. Es ist effizient und weit verbreitet.
• JSON Schema: Eine Vokabulardefinition, die es Ihnen ermöglicht, JSON-Dokumente zu kommentieren und zu validieren. Obwohl JSON selbst schemalos ist, bietet JSON Schema eine Möglichkeit, Schemata für JSON-Daten zu definieren.
• Thrift: Entwickelt von Facebook, ist Thrift eine Interface Definition Language (IDL), die zur Definition von Datentypen und Diensten verwendet wird.

Diese Formate stellen bei Verwendung mit entsprechenden Bibliotheken sicher, dass Daten gemäß einem definierten Schema serialisiert und deserialisiert werden und Typ-Fehlpaarungen während des Prozesses aufdecken.

2. Schemaregister

Ein Schemaregister ist eine zentrale Komponente, die Schemata für Ihre Nachrichtentypen speichert und verwaltet. Beliebte Schemaregister sind:

• Confluent Schema Registry: Für Apache Kafka ist dies ein De-facto-Standard, der Avro, JSON Schema und Protobuf unterstützt.
• AWS Glue Schema Registry: Ein vollständig verwaltetes Schemaregister, das Avro, JSON Schema und Protobuf unterstützt und sich gut in AWS-Dienste wie Kinesis und MSK integriert.
• Google Cloud Schema Registry: Als Teil des Pub/Sub-Angebots von Google Cloud ermöglicht es die Verwaltung von Schemata für Pub/Sub-Themen.

Schemaregister ermöglichen:

• Schema-Versionierung: Verwaltung verschiedener Schemaversionen, entscheidend für die reibungslose Handhabung der Schema-Entwicklung.
• Kompatibilitätsprüfungen: Definition von Kompatibilitätsregeln (z. B. Abwärts-, Vorwärts-, Vollkompatibilität), um sicherzustellen, dass Schema-Updates keine bestehenden Konsumenten oder Produzenten unterbrechen.
• Schema-Erkennung: Konsumenten können das mit einer bestimmten Nachricht verbundene Schema erkennen.

3. Integration mit Nachrichtenbrokern

Die Wirksamkeit von Typsicherheit hängt davon ab, wie gut sie mit Ihrem gewählten Nachrichtenbroker integriert ist:

• Apache Kafka: Oft mit Confluent Schema Registry verwendet. Kafka-Konsumenten und -Produzenten können so konfiguriert werden, dass sie Avro- oder Protobuf-Serialisierung verwenden, wobei Schemata vom Register verwaltet werden.
• RabbitMQ: Obwohl RabbitMQ selbst ein Allzweck-Nachrichtenbroker ist, können Sie Typsicherheit erzwingen, indem Sie Bibliotheken verwenden, die Nachrichten vor dem Senden an RabbitMQ-Warteschlangen in Avro, Protobuf oder JSON Schema serialisieren. Der Konsument verwendet dann dieselben Bibliotheken und Schema-Definitionen zur Deserialisierung.
• Amazon SQS/SNS: Ähnlich wie RabbitMQ können SQS/SNS mit benutzerdefinierter Serialisierungslogik verwendet werden. Für verwaltete Lösungen kann AWS Glue Schema Registry in Dienste wie Kinesis (das dann in SQS gespeist werden kann) oder direkt in Dienste integriert werden, die Schema-Validierung unterstützen.
• Google Cloud Pub/Sub: Unterstützt die Schema-Verwaltung für Pub/Sub-Themen, sodass Sie Schemata mithilfe von Avro oder Protocol Buffers definieren und erzwingen können.

Best Practices für die Implementierung typsicherer Nachrichtenwarteschlangen

Um die Vorteile typsicherer Nachrichtenwarteschlangen zu maximieren, beachten Sie diese Best Practices:

• Klare Nachrichtenverträge definieren: Behandeln Sie Nachrichtenschemata als öffentliche APIs. Dokumentieren Sie sie gründlich und beziehen Sie alle relevanten Teams in ihre Definition ein.
• Ein Schemaregister verwenden: Zentralisieren Sie die Schema-Verwaltung. Dies ist entscheidend für Versionierung, Kompatibilität und Governance.
• Ein geeignetes Serialisierungsformat wählen: Berücksichtigen Sie Faktoren wie Leistung, Schema-Entwicklungsfähigkeiten, Ökosystem-Unterstützung und Datengröße bei der Auswahl von Avro, Protobuf oder anderen Formaten.
• Schema-Versionierung strategisch implementieren: Definieren Sie klare Regeln für die Schema-Entwicklung. Verstehen Sie den Unterschied zwischen Abwärts-, Vorwärts- und Vollkompatibilität und wählen Sie die Strategie, die am besten zu den Bedürfnissen Ihres Systems passt.
• Schema-Validierung automatisieren: Integrieren Sie die Schema-Validierung in Ihre CI/CD-Pipelines, um Fehler frühzeitig zu erkennen.
• Code aus Schemata generieren: Nutzen Sie Werkzeuge, um automatisch Datenklassen oder Schnittstellen in Ihren Programmiersprachen aus Ihren Schemata zu generieren. Dies stellt sicher, dass Ihr Anwendungscode immer mit den Nachrichtenverträgen synchronisiert ist.
• Schema-Entwicklung sorgfältig handhaben: Priorisieren Sie bei der Entwicklung von Schemata nach Möglichkeit die Abwärtskompatibilität, um bestehende Konsumenten nicht zu stören. Wenn Abwärtskompatibilität nicht möglich ist, planen Sie eine schrittweise Einführung und kommunizieren Sie Änderungen effektiv.
• Schema-Nutzung überwachen: Verfolgen Sie, welche Schemata verwendet werden, von wem und deren Kompatibilitätsstatus. Dies hilft bei der Identifizierung potenzieller Probleme und der Planung von Migrationen.
• Ihre Teams schulen: Stellen Sie sicher, dass alle Entwickler, die mit Nachrichtenwarteschlangen arbeiten, die Bedeutung von Typsicherheit, Schema-Verwaltung und den ausgewählten Werkzeugen verstehen.

Fallstudie: Globale E-Commerce-Bestellabwicklung

Stellen Sie sich ein globales E-Commerce-Unternehmen mit Microservices für Katalogverwaltung, Bestellabwicklung, Inventur und Versand vor, das über verschiedene Kontinente hinweg tätig ist. Diese Dienste kommunizieren über eine Kafka-basierte Nachrichtenwarteschlange.

Szenario ohne Typsicherheit: Der Bestellabwicklungsservice erwartet ein `OrderPlaced`-Ereignis mit `order_id` (string), `customer_id` (string) und `items` (ein Array von Objekten mit `product_id` und `quantity`). Wenn das Team des Katalogdienstes in Eile eine Aktualisierung vornimmt, bei der `order_id` als Integer gesendet wird, stürzt der Bestellabwicklungsservice wahrscheinlich ab oder verarbeitet Bestellungen falsch, was zu Kundenunzufriedenheit und Umsatzeinbußen führt. Das Debugging über verteilte Dienste hinweg kann ein Albtraum sein.

Szenario mit Typsicherheit (unter Verwendung von Avro und Confluent Schema Registry):

1. Schema-Definition: Ein `OrderPlaced`-Ereignisschema wird mit Avro definiert, das `orderId` als `string`, `customerId` als `string` und `items` als Array von Datensätzen mit `productId` (string) und `quantity` (int) angibt. Dieses Schema wird im Confluent Schema Registry registriert.
2. Produzent (Katalogdienst): Der Katalogdienst ist so konfiguriert, dass er den Avro-Serializer verwendet und auf das Schemaregister verweist. Wenn er versucht, eine `orderId` als Integer zu senden, lehnt der Serializer die Nachricht ab, da sie nicht mit dem registrierten Schema übereinstimmt. Dieser Fehler wird sofort während der Entwicklung oder beim Testen erkannt.
3. Konsument (Bestellabwicklungsservice): Der Bestellabwicklungsservice verwendet den Avro-Deserializer, der ebenfalls mit dem Schemaregister verbunden ist. Er kann `OrderPlaced`-Ereignisse vertrauensvoll verarbeiten, da er weiß, dass sie immer die definierte Struktur und die definierten Typen aufweisen.
4. Schema-Entwicklung: Später beschließt das Unternehmen, der `OrderPlaced`-Nachricht einen optionalen `discountCode` (string) hinzuzufügen. Sie aktualisieren das Schema im Register und kennzeichnen `discountCode` als nullbar oder optional. Sie stellen sicher, dass dieses Update abwärtskompatibel ist. Bestehende Konsumenten, die `discountCode` noch nicht erwarten, ignorieren ihn einfach, während neuere Versionen des Katalogdienstes ihn senden können.

Dieser systematische Ansatz verhindert Probleme mit der Datenintegrität, beschleunigt die Entwicklung und macht das Gesamtsystem weitaus robuster und einfacher zu verwalten, selbst für ein globales Team, das an einem komplexen System arbeitet.

Fazit

Typsichere Nachrichtenwarteschlangen sind keine bloße Luxusausstattung, sondern eine Notwendigkeit für den Aufbau moderner, widerstandsfähiger und skalierbarer ereignisgesteuerter Architekturen. Durch die formale Definition und Durchsetzung von Nachrichtenschemata mildern wir eine erhebliche Klasse von Fehlern, die verteilte Systeme plagen. Sie befähigen Entwickler mit Vertrauen in die Datenintegrität, straffen die Entwicklung und bilden das Fundament für fortgeschrittene Muster wie Event Sourcing und CQRS.

Da Organisationen zunehmend Microservices und verteilte Systeme einführen, ist die Akzeptanz von Typsicherheit in ihrer Nachrichtenwarteschlangen-Infrastruktur eine strategische Investition. Sie führt zu vorhersehbareren Systemen, weniger Produktionsvorfällen und einer produktiveren Entwicklungserfahrung. Unabhängig davon, ob Sie eine globale Plattform oder einen spezialisierten Microservice entwickeln, wird die Priorisierung der Typsicherheit in Ihrer ereignisgesteuerten Kommunikation Ihnen Vorteile in Bezug auf Zuverlässigkeit, Wartbarkeit und langfristigen Erfolg bringen.